Внедрение заголовков веб-безопасности: политика Content Security Policy (CSP) на JavaScript

В современном цифровом мире веб-безопасность имеет первостепенное значение. Защита вашего сайта и его пользователей от вредоносных атак — это уже не опция, а необходимость. Межсайтовый скриптинг (XSS) остается распространенной угрозой, и одной из самых эффективных защит является внедрение строгой политики безопасности контента (Content Security Policy, CSP). Это руководство посвящено использованию JavaScript для управления и развертывания CSP, что обеспечивает динамичный и гибкий подход к защите ваших веб-приложений на глобальном уровне.

Что такое Content Security Policy (CSP)?

Content Security Policy (CSP) — это заголовок HTTP-ответа, который позволяет вам контролировать, какие ресурсы пользовательский агент (браузер) может загружать для данной страницы. По сути, он действует как "белый список", определяя источники, из которых могут загружаться скрипты, таблицы стилей, изображения, шрифты и другие ресурсы. Четко определяя эти источники, вы можете значительно уменьшить поверхность атаки вашего сайта, что сильно затрудняет злоумышленникам внедрение вредоносного кода и выполнение XSS-атак. Это важный уровень эшелонированной обороны (defence in depth).

Зачем использовать JavaScript для внедрения CSP?

Хотя CSP можно настроить непосредственно в конфигурации вашего веб-сервера (например, в файле .htaccess для Apache или в конфигурационном файле Nginx), использование JavaScript предлагает несколько преимуществ, особенно в сложных или динамических приложениях:

• Динамическая генерация политики: JavaScript позволяет динамически генерировать политики CSP в зависимости от ролей пользователей, состояния приложения или других условий времени выполнения. Это особенно полезно в одностраничных приложениях (SPA) или приложениях, которые в значительной степени полагаются на рендеринг на стороне клиента.
• CSP на основе Nonce: Использование nonce (криптографически случайных, одноразовых токенов) — это высокоэффективный способ защиты встроенных скриптов и стилей. JavaScript может генерировать эти nonce и добавлять их как в заголовок CSP, так и в теги встроенных скриптов/стилей.
• CSP на основе хэшей: Для статических встроенных скриптов или стилей вы можете использовать хэши, чтобы добавить в "белый список" определенные фрагменты кода. JavaScript может вычислять эти хэши и включать их в заголовок CSP.
• Гибкость и контроль: JavaScript дает вам тонкий контроль над заголовком CSP, позволяя изменять его на лету в зависимости от конкретных потребностей приложения.
• Отладка и отчетность: JavaScript можно использовать для сбора отчетов о нарушениях CSP и их отправки на центральный сервер логирования для анализа, что помогает выявлять и устранять проблемы безопасности.

Настройка CSP на JavaScript

Общий подход включает в себя генерацию строки заголовка CSP в JavaScript и последующую установку соответствующего заголовка HTTP-ответа на стороне сервера (обычно через ваш бэкенд-фреймворк). Мы рассмотрим конкретные примеры для разных сценариев.

1. Генерация Nonce

Nonce (number used once — число, используемое один раз) — это случайно сгенерированное уникальное значение, используемое для добавления в "белый список" определенных встроенных скриптов или стилей. Вот как можно сгенерировать nonce в JavaScript:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // For IE support
  if (!crypto || !crypto.getRandomValues) {
    // Fallback for older browsers without crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Generated Nonce:", nonce);

            

              
                Copy
              
            
          

Этот фрагмент кода генерирует криптографически безопасный nonce с использованием встроенного в браузер API crypto (если он доступен) и использует менее безопасный метод в качестве запасного варианта, если API не поддерживается. Сгенерированный nonce затем кодируется в base64 для использования в заголовке CSP.

2. Внедрение Nonce во встроенные скрипты

После того как у вас есть nonce, вам нужно внедрить его как в заголовок CSP, так и в тег <script>:

HTML:

            <script nonce="YOUR_NONCE_HERE">
  // Your inline script code here
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

JavaScript (Backend):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Example using Node.js with Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Pass the nonce to the view or template engine
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Важные замечания:

• Замените YOUR_NONCE_HERE в HTML на фактически сгенерированный nonce. Это часто делается на стороне сервера с использованием шаблонизатора. Приведенный выше пример иллюстрирует передачу nonce в шаблонизатор.
• Директива script-src в заголовке CSP теперь включает 'nonce-${nonce}', что позволяет выполняться скриптам с соответствующим nonce.
• 'strict-dynamic' добавляется в директиву `script-src`. Эта директива указывает браузеру доверять скриптам, загруженным доверенными скриптами. Если у тега script есть действительный nonce, то любой скрипт, который он загружает динамически (например, с помощью `document.createElement('script')`), также будет считаться доверенным. Это уменьшает необходимость добавлять в "белый список" многочисленные отдельные домены и URL-адреса CDN и значительно упрощает поддержку CSP.
• 'unsafe-inline' в целом не рекомендуется использовать вместе с nonce, так как это ослабляет CSP. Однако здесь он включен в демонстрационных целях и должен быть удален в производственной среде. Удалите это, как только сможете.

3. Генерация хэшей для встроенных скриптов

Для статических встроенных скриптов, которые редко меняются, вы можете использовать хэши вместо nonce. Хэш — это криптографический дайджест содержимого скрипта. Если содержимое скрипта изменится, хэш также изменится, и браузер заблокирует скрипт.

Вычисление хэша:

Вы можете использовать онлайн-инструменты или утилиты командной строки, такие как OpenSSL, для генерации хэша SHA256 вашего встроенного скрипта. Например:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Пример:

Допустим, ваш встроенный скрипт выглядит так:

            <script>
  console.log("Hello from inline script!");
</script>
            

              
                Copy
              
            
          

Хэш SHA256 этого скрипта (без тегов <script>) может быть таким:

            sha256-YOUR_HASH_HERE
            

              
                Copy
              
            
          

Заголовок CSP:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-YOUR_HASH_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Замените YOUR_HASH_HERE на фактический хэш SHA256 содержимого вашего скрипта.

Важные соображения по поводу хэшей:

• Хэш должен вычисляться на основе точного содержимого скрипта, включая пробельные символы. Любые изменения в скрипте, даже на один символ, сделают хэш недействительным.
• Хэши лучше всего подходят для статических скриптов, которые редко меняются. Для динамических скриптов лучшим вариантом являются nonce.

4. Установка заголовка CSP на сервере

Последний шаг — это установка HTTP-заголовка ответа Content-Security-Policy на вашем сервере. Точный метод зависит от вашей серверной технологии.

Node.js с Express:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Make nonce available to templates
  next();
});
            

              
                Copy
              
            
          

Python с Flask:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Example</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hello from inline script!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Хотя это не рекомендуется для динамического CSP, вы *можете* установить статический CSP с помощью .htaccess:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;";
            

              
                Copy
              
            
          

Важные замечания:

• Замените 'self' на фактический домен(ы), с которого вы хотите разрешить загрузку ресурсов.
• Будьте предельно осторожны при использовании 'unsafe-inline' и 'unsafe-eval'. Эти директивы значительно ослабляют CSP и их следует избегать по возможности.
• Используйте upgrade-insecure-requests для автоматического обновления всех HTTP-запросов до HTTPS.
• Рассмотрите возможность использования report-uri или report-to для указания конечной точки для получения отчетов о нарушениях CSP.

Объяснение директив CSP

CSP использует директивы для указания разрешенных источников для различных типов ресурсов. Вот краткий обзор некоторых из наиболее распространенных директив:

• default-src: Указывает источник по умолчанию для всех ресурсов, которые явно не охвачены другими директивами.
• script-src: Указывает разрешенные источники для JavaScript.
• style-src: Указывает разрешенные источники для таблиц стилей.
• img-src: Указывает разрешенные источники для изображений.
• font-src: Указывает разрешенные источники для шрифтов.
• media-src: Указывает разрешенные источники для аудио и видео.
• object-src: Указывает разрешенные источники для плагинов (например, Flash). В целом, следует установить это значение в 'none', чтобы отключить плагины.
• frame-src: Указывает разрешенные источники для фреймов и iframe.
• connect-src: Указывает разрешенные источники для соединений XMLHttpRequest, WebSocket и EventSource.
• base-uri: Указывает разрешенные базовые URI для документа.
• form-action: Указывает разрешенные конечные точки для отправки форм.
• upgrade-insecure-requests: Указывает пользовательскому агенту обрабатывать все небезопасные URL-адреса сайта (обслуживаемые по HTTP) так, как если бы они были заменены безопасными URL-адресами (обслуживаемыми по HTTPS). Эта директива предназначена для веб-сайтов, которые были полностью переведены на HTTPS.
• report-uri: Указывает URI, на который браузер должен отправлять отчеты о нарушениях CSP. Эта директива устарела в пользу `report-to`.
• report-to: Указывает именованную конечную точку, на которую браузер должен отправлять отчеты о нарушениях CSP.

Ключевые слова списка источников CSP

Каждая директива использует список источников для указания разрешенных источников. Список источников может содержать следующие ключевые слова:

• 'self': Разрешает ресурсы с того же источника (схема, хост и порт).
• 'none': Запрещает ресурсы с любого источника.
• 'unsafe-inline': Разрешает встроенные скрипты и стили. Избегайте этого по возможности.
• 'unsafe-eval': Разрешает использование eval() и связанных функций. Избегайте этого по возможности.
• 'strict-dynamic': Указывает, что доверие, которое браузер оказывает скрипту на странице из-за сопутствующего nonce или хэша, должно распространяться на скрипты, загружаемые этим скриптом.
• 'data:': Разрешает ресурсы, загруженные через схему data: (например, встроенные изображения). Используйте с осторожностью.
• 'mediastream:': Разрешает ресурсы, загруженные через схему mediastream:.
• https:: Разрешает ресурсы, загруженные по HTTPS.
• http:: Разрешает ресурсы, загруженные по HTTP. В целом не рекомендуется.
• *: Разрешает ресурсы с любого источника. Избегайте этого; это сводит на нет цель CSP.

Отчеты о нарушениях CSP

Отчеты о нарушениях CSP имеют решающее значение для мониторинга и отладки вашей CSP. Когда ресурс нарушает CSP, браузер может отправить отчет на указанный URI.

Настройка конечной точки для отчетов:

Вам понадобится серверная конечная точка для получения и обработки отчетов о нарушениях CSP. Отчет отправляется в виде JSON-нагрузки.

Пример (Node.js с Express):

            app.post('/csp-report', (req, res) => {
  console.log('CSP Violation Report:', req.body);
  // Process the report (e.g., log to a file or database)
  res.status(204).end(); // Respond with a 204 No Content status
});
            

              
                Copy
              
            
          

Настройка директивы report-uri или report-to:

Добавьте директиву report-uri или `report-to` в ваш заголовок CSP. `report-uri` устарела, поэтому предпочтительнее использовать `report-to`.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

Вам также необходимо настроить конечную точку Reporting API с помощью заголовка `Report-To`.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }
            

              
                Copy
              
            
          

Примечание:

• Заголовок `Report-To` должен устанавливаться при каждом запросе к вашему серверу, иначе браузер может отбросить конфигурацию.
• `report-uri` менее безопасен, чем `report-to`, поскольку не позволяет шифровать отчет с помощью TLS, и он устарел, поэтому предпочтительнее использовать `report-to`.

Пример отчета о нарушении CSP (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-YOUR_NONCE_HERE'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-YOUR_NONCE_HERE'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}
            

              
                Copy
              
            
          

Анализируя эти отчеты, вы можете выявлять и исправлять нарушения CSP, обеспечивая безопасность вашего сайта.

Лучшие практики внедрения CSP

• Начинайте с ограничительной политики: Начните с политики, которая разрешает ресурсы только с вашего собственного источника, и постепенно ослабляйте ее по мере необходимости.
• Используйте nonce или хэши для встроенных скриптов и стилей: Избегайте использования 'unsafe-inline' по возможности.
• Используйте 'strict-dynamic' для упрощения поддержки CSP.
• Избегайте использования 'unsafe-eval': Если вам нужно использовать eval(), рассмотрите альтернативные подходы.
• Используйте upgrade-insecure-requests: Автоматически обновляйте все HTTP-запросы до HTTPS.
• Внедрите отчеты о нарушениях CSP: Отслеживайте нарушения вашей CSP и оперативно их исправляйте.
• Тщательно тестируйте свою CSP: Используйте инструменты разработчика в браузере для выявления и решения любых проблем с CSP.
• Используйте валидатор CSP: Онлайн-инструменты могут помочь вам проверить синтаксис заголовка CSP и выявить потенциальные проблемы.
• Рассмотрите возможность использования фреймворка или библиотеки для CSP: Существует несколько фреймворков и библиотек, которые могут помочь упростить внедрение и управление CSP.
• Регулярно пересматривайте свою CSP: По мере развития вашего приложения может потребоваться обновление CSP.
• Обучайте свою команду: Убедитесь, что ваши разработчики понимают CSP и ее важность.
• Развертывайте CSP поэтапно: Начните с развертывания CSP в режиме "только отчеты" (report-only), чтобы отслеживать нарушения, не блокируя ресурсы. Убедившись в правильности вашей политики, вы можете включить ее в режиме принудительного исполнения.
• Документируйте свою CSP: Ведите учет вашей политики CSP и причин, стоящих за каждой директивой.
• Помните о совместимости с браузерами: Поддержка CSP варьируется в разных браузерах. Тестируйте свою CSP в разных браузерах, чтобы убедиться, что она работает как ожидается.
• Приоритет безопасности: CSP — это мощный инструмент для повышения веб-безопасности, но это не панацея. Используйте его в сочетании с другими лучшими практиками безопасности для защиты вашего сайта от атак.
• Рассмотрите возможность использования брандмауэра веб-приложений (WAF): WAF может помочь вам применять политики CSP и защищать ваш сайт от других типов атак.

Распространенные проблемы при внедрении CSP

• Сторонние скрипты: Определение и добавление в "белый список" всех доменов, необходимых для сторонних скриптов, может быть сложной задачей. По возможности используйте `strict-dynamic`.
• Встроенные стили и обработчики событий: Преобразование встроенных стилей и обработчиков событий во внешние таблицы стилей и файлы JavaScript может занимать много времени.
• Проблемы совместимости с браузерами: Поддержка CSP варьируется в разных браузерах. Тестируйте свою CSP в разных браузерах, чтобы убедиться, что она работает как ожидается.
• Накладные расходы на обслуживание: Поддержание актуальности вашей CSP по мере развития приложения может быть проблемой.
• Влияние на производительность: CSP может незначительно снизить производительность из-за необходимости проверки ресурсов на соответствие политике.

Глобальные аспекты CSP

При внедрении CSP для глобальной аудитории учитывайте следующее:

• Провайдеры CDN: Если вы используете CDN, убедитесь, что вы добавили в "белый список" соответствующие домены CDN. Многие CDN предлагают региональные конечные точки; их использование может улучшить производительность для пользователей в разных географических точках.
• Ресурсы для конкретных языков: Если ваш сайт поддерживает несколько языков, убедитесь, что вы добавили в "белый список" необходимые ресурсы для каждого языка.
• Региональные нормативные акты: Будьте в курсе любых региональных нормативных актов, которые могут повлиять на ваши требования к CSP.
• Доступность: Убедитесь, что ваша CSP случайно не блокирует ресурсы, необходимые для функций доступности.
• Тестирование в разных регионах: Тестируйте свою CSP в разных географических регионах, чтобы убедиться, что она работает как ожидается для всех пользователей.

Заключение

Внедрение надежной политики безопасности контента (CSP) является решающим шагом в защите ваших веб-приложений от XSS-атак и других угроз. Используя JavaScript для динамической генерации и управления вашей CSP, вы можете достичь более высокого уровня гибкости и контроля, обеспечивая безопасность и защиту вашего сайта в постоянно меняющемся ландшафте угроз. Не забывайте следовать лучшим практикам, тщательно тестировать свою CSP и постоянно отслеживать ее на предмет нарушений. Безопасное кодирование, эшелонированная оборона и хорошо реализованная CSP являются ключом к обеспечению безопасного просмотра для глобальной аудитории.